Method and apparatus for a SIP client manager

ABSTRACT

A method, apparatus, system, and computer program product for communicating using Session Initiation Protocol (SIP) is provided. The method, apparatus, system and computer program product provide mechanisms by which simplified messages may be utilized by client applications such that the client applications need not maintain information pertaining to the routing of messages. The system includes a network interface and a SIP client manager that receives SIP messages through the network interface. The SIP client manager contains a SIP management module and an X-SIP client module. The SIP management module contains a SIP message modifier for modifying incoming messages and outgoing messages in accordance with context information or state information for a session associated with a SIP message, and the SIP management module also contains input/output controllers for receiving, sending, or forwarding SIP messages. The X-SIP client module contains an input/output controller for receiving and sending SIP messages and also contains a SIP application programming interface (API) for handling SIP messages for a SIP-enabled application.

FIELD OF THE INVENTION

[0001] The present invention relates generally to an improvedcommunications system and in particular to a method and apparatus forestablishing and maintaining a communication session. Still moreparticularly, the present invention provides a method and apparatus fora distributed processing manager using Session Initiation Protocol.

BACKGROUND OF THE INVENTION

[0002] Session Initiation Protocol (SIP) is an application-layer controlprotocol for transporting call setup, routing authentication and otherfeature messages to endpoints within the IP domain, whether thosemessages originate from outside the IP cloud over PSTN resources orwithin the cloud. These sessions include Internet multimediaconferences, Internet telephone calls, and multimedia distribution.Members in a session can communicate via multicast, via a mesh ofunicast relations, or a combination of these. SIP can be used toinitiate sessions as well as invite members to sessions that have beenadvertised and established by other means.

[0003] SIP is a text-based protocol that uses the ISO 10646 characterset in UTF-8 encoding. A SIP message is either a request from a clientto a server or a response from a server to a client. Both of these typesof messages contain a start line, one or more header fields, or“headers”, an empty line indicating the end of the header fields, and anoptional message body.

[0004] In processing a SIP message, different SIP message headers havedifferent characteristics with respect to the frequency of occurrence inSIP messages. Some headers, such as a “To” header, are generic headersthat appear only once while other headers, such as “Via” headers, aregeneric headers that can appear any number of times. The “Via” headers,for example, provide information pertaining to the route through which aSIP communication must pass between SIP clients.

[0005] Headers, such as “CallerID”, “To”, and “From” headers areessential for establishing the context of the SIP message. However, fromthe viewpoint of an application program, maintaining other context andstate information related to a session, such as storing a long sequenceof Via headers, detracts from the essential task of providing adistributed application with particular functionality.

[0006] Therefore, it would be advantageous to have an apparatus andmethod for managing application non-essential information, such asrouting information. It would further be advantageous to have anapparatus and method that presents an application program with asimplified SIP environment.

SUMMARY OF THE INVENTION

[0007] The present invention provides an apparatus, method, and systemfor communication using Session Initiation Protocol (SIP). A dataprocessing system, according to the present invention, contains anetwork interface and a SIP client manager that receives SIP messagesthrough the network interface. The SIP client manager contains a SIPmanagement module and an X-SIP client module. The SIP management modulecontains a SIP message modifier for modifying incoming messages andoutgoing messages in accordance with context information or stateinformation for a session associated with a SIP message. The SIPmanagement module also contains input/output controllers for receiving,sending, and forwarding SIP messages.

[0008] The X-SIP client module contains an input/output controller forreceiving and sending SIP messages and a SIP application programminginterface (API) for handling SIP messages for a SIP-enabled application.The X-SIP client module performs conversion of client applicationformatted messages, into X-SIP messages, i.e. modified SIP messages, andvice versa. The SIP management module and the X-SIP client modulecommunicate via a socket for transmitting these messages between the SIPmanagement module and an X-SIP client module, thereby creating adistributed SIP client architecture for managing SIP information.

[0009] When SIP messages are sent from a client application to a SIPserver, the message from the client application is first received by theX-SIP client module. The X-SIP client module converts client applicationmessages into simplified SIP messages containing, for example, the “To,”“From,” and the “CallerID” headers. The simplified SIP message isforwarded to the SIP management module which performs context managementto determine routing information for the simplified SIP message. The SIPmanagement module adds the routing information to the simplified SIPmessage to thereby create a non-simplified SIP message. Thenon-simplified SIP message is then forwarded to a SIP server via an IPnetwork.

[0010] When SIP messages are received from a SIP server, the SIP messageis first received by the SIP management module. The SIP managementmodule strips the SIP message of the routing information and stores therouting information in memory. The resulting simplified SIP message isforwarded to the X-SIP client module. The X-SIP client module thenconverts the simplified SIP message into a client application message.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The novel features believed characteristic of the invention areset forth in the appended claims. The invention itself, however, as wellas a preferred mode of use, further objectives and advantages thereof,will best be understood by reference to the following detaileddescription of an illustrative embodiment when read in conjunction withthe accompanying drawings, wherein like numerals designate likeelements, and wherein:

[0012]FIG. 1 is an exemplary block diagram of a wireless communicationsnetwork in which the present invention may be implemented in accordancewith a preferred embodiment of the present invention;

[0013]FIG. 2 is an exemplary block diagram of a data processing systemin which the present invention may be implemented;

[0014]FIG. 3 is an exemplary block diagram of a SIP client manageraccording to the present invention;

[0015]FIG. 4 is an exemplary block diagram of a SIP client manager foruse with multiple clients in accordance with the present invention;

[0016]FIG. 5 is an exemplary block diagram of a SIP client manager beingused in conjunction with an IP network, in accordance with the presentinvention;

[0017]FIG. 6 is an exemplary block diagram showing the major classgroupings in the X-SIP client module in accordance with the presentinvention;

[0018]FIG. 7 is an exemplary diagram of a class hierarchy for themessage processor classes in the X-SIP client module;

[0019]FIG. 8 is an exemplary diagram of a class hierarchy for themessage data classes in the X-SIP client module;

[0020]FIG. 9 is an exemplary diagram of a class hierarchy for the headerclasses in the X-SIP client module;

[0021]FIG. 10 is an exemplary event flow trace diagram of outgoingmessage processing in the X-SIP client module in accordance with thepresent invention;

[0022]FIG. 11 is an exemplary event flow trace diagram of receivedmessage processing in the X-SIP client module in accordance with thepresent invention;

[0023]FIG. 12 is an exemplary data flow diagram illustrating processingof a SIP message in the SIP client manager in accordance with thepresent invention;

[0024]FIG. 13 is an exemplary block diagram of the SIP management modulestructure in accordance with the present invention; and

[0025]FIG. 14 is an exemplary diagram illustrating a comparison of thestatus line and an X-SIP header in accordance with the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0026]FIG. 1 is an exemplary block diagram of a communications network100 in which the present invention may be implemented. Communicationsnetwork 100 includes a Session Initiation Protocol (SIP) proxy server104, a web server 106, and a wireless proxy 108. SIP proxy server 104sends and receives data packets to and from a Public Switch TelephoneNetwork (PSTN) 102 via a PSTN gateway (not shown). The PSTN 102 may thenforward the data packets to telephones 112 and other communicationdevices that may be connected to the PSTN 102. The SIP proxy server 104may also send and receive data packets from computing device 118 using,for example, Transmission Control Protocol (TCP) or User DatagramProtocol (UDP). The SIP proxy server 104 communicates with the webserver 106 using SIP.

[0027] SIP is a textual-based signaling protocol for creating,modifying, and terminating sessions. These sessions can be multimediaconferences, Internet telephone calls, and similar applicationsconsisting of one or more media types such as audio, video, orwhiteboard. SIP invitations are used to create sessions and carrysession descriptions, which allow participants to agree on a set ofcompatible media types. SIP requests can be sent either over TCP or UDPcommunication links.

[0028] Web server 106 may be connected to other servers and electronicdevices (not shown) via a network such as the Internet. Web server 106may also be connected to a wireless proxy server 108, which may be aproprietary server that communicates with portable communication and/orcomputing devices, such as a personal digital assistant (PDA) 114 or acellular telephone, through wireless communication base station 110 andwireless communication link 122. Web server 106 may communicate withwireless proxy device 108 using the Hypertext Transfer Protocol (HTTP).Web server 106 may also communicate with other computing devices, suchas computer 116, over communications link 120.

[0029] When a user of telephone 112 wishes to establish a communicationconnection with PDA 114, for example, the user initiates thecommunication using a telephone-based application. This may involvesimply picking up the receiver of the telephone 112 and dialing adesignated number for directing the telephone call via the PSTN 102 tothe SIP proxy server 104, for example.

[0030] In response to receiving the call from the PSTN 102, the PSTNgateway (not shown) creates a SIP message which is routed by the SIPproxy server 104 to establish a communication connection between the SIPproxy server 104 and the web server 106. The SIP message includes allnecessary information for the web server 106 to establish acommunication connection to the wireless proxy device 108 and thereby,to the PDA 114 via the wireless base station 110 and communicationconnection 122. The PDA 114 may respond to the SIP message by sending aresponse signal in either a SIP format or another communication format,so long as the web server 106 is capable of converting the responsemessage format into a format recognized by the SIP proxy server 104,such as a SIP format.

[0031] With the present invention, a SIP client manager apparatus isprovided in communication links between the SIP proxy server and thePSTN 102, web server 106, and computing device 118. The SIP clientmanager apparatus may be a separate hardware device provided in eachcommunication link, a single hardware device through which each of thecommunication links pass, or may be embodied in software running on oneor more of the SIP proxy server 104, the PSTN 102, the web server 106,and the computing device 118. The SIP client manager apparatus providesa mechanism by which simplified SIP messages may be sent to and from SIPclients, as will be described hereafter.

[0032]FIG. 2 is an exemplary block diagram of a data processing system200 for implementing the SIP client manager device according to thepresent invention. The data processing system 200 may be implemented ona computer in which code or instructions implementing the processes ofthe present invention may be located. The data processing system 200employs a peripheral component interconnect (PCI) local busarchitecture. Although the depicted example employs a PCI bus, other busarchitectures, such as Accelerated Graphics Port (AGP) and IndustryStandard Architecture (ISA), may be used.

[0033] The data processing system 200 includes a processor 210 and mainmemory 214 connected to PCI local bus 250 through PCI bridge 212. ThePCI bridge 212 may also include an integrated memory controller andcache memory for processor 210.

[0034] Additional connections to PCI local bus 250 may be made throughdirect component interconnection or through add-in boards. In thedepicted example, storage device 216, network interface 218, andInput/Output (I/O) device 220 are connected to the PCI local bus 250 bydirect component connection, however, some or all of these devices maybe connected through add-in boards.

[0035] An operating system runs on processor 210 and is used tocoordinate and provide control of various components within the dataprocessing system 200. In addition, an object oriented programmingsystem, such as Java, may run in conjunction with the operation systemand may provide calls to the operation system from Java programs orapplications executing on the data processing system 200. Instructionsfor the operation system, the object-oriented programming system, andapplications or programs may be located in the storage device 216, forexample.

[0036] The data processing system 200 includes software for establishingsessions using SIP. The data processing system 200 receives applicationspecific messages from SIP client devices via the I/O device 220 invarious application specific formats, converts the application specificformats into a SIP messages, and transmits the SIP messages to the SIPproxy server 104. In addition, the data processing system 200 receivesSIP messages from the SIP proxy server 104, converts the SIP messagesinto an application specific format, and forwards the applicationspecific formatted messages to an appropriate SIP client device.

[0037] The depicted example in FIG. 2 and above-described examples arenot intended to imply architectural limitations. Those of ordinary skillin the art will appreciate that the hardware in FIG. 2 may varydepending on the implementation. Other internal hardware or peripheraldevices, such as flash ROM, optical disk drives, and the like, may beused in addition to or in place of the hardware depicted in FIG. 2.Furthermore, the processes of the present invention may be applied to amultiprocessor system.

[0038]FIG. 3 is an exemplary block diagram of the SIP client managerdevice 300 in accordance with a preferred embodiment of the invention.The SIP client manager device 300 includes an X-SIP client module 310,an X-SIP module socket 315, a SIP management module 330, SIP managementmodule sockets 325 and 335, and a communication link 320 between theX-SIP module socket 315 and the SIP management module 330. Thecommunication link 320 may be, for example, an internal TCPcommunication link, a network communication link, or the like.

[0039] Service requests from a client application 340 for services froma SIP server 104 are received by the X-SIP client module 310. The X-SIPclient module 310 converts the application specific formatted servicerequests from the client application 340 into a simplified SIP messageformat. This simplified SIP message is then transmitted via socket 315,communication link 320, and socket 325 to the SIP management module 330.The SIP management module 330 performs appropriate processing on thesimplified SIP message to add appropriate routing headers to thesimplified SIP message for use in routing the service request message tothe SIP server 104.

[0040] Similarly, when SIP messages are received from the SIP server 104destined for the client application 340, the SIP messages are receivedby the SIP management module 330 via the SIP management module socket335. The SIP management module 330 removes all “unnecessary” headerinformation, such as routing headers, e.g. “Via” headers, from the SIPmessages, stores the removed header information in a memory, andforwards a simplified SIP message to the client application via thesockets 315, 325, communication link 320, and X-SIP client module 310.

[0041] Although SIP is used to establish the communication linksnecessary to obtain services from an application server (such as webserver 106), the actual service itself may use any one of a wide varietyof protocols depending on the nature of the service. Thus, for example,the services provided by the application server 106 may make use ofHTTP, TCP, UDP, real time streaming protocol (RTSP), and the like.

[0042] The X-SIP Client Module 310 is a simplified protocol thatcontains some of the components that handle information essential forcommunications with the SIP management module 330. For example, thesimplified protocol may include the “CallerID”, “To”, and “From” headersas essential for determining the system context. However, a sequence of“Via” headers may not be included in the simplified protocol and may bemaintained by the SIP management module 330.

[0043] The X-SIP client module 310 includes X-SIP client module socket315 for communication with SIP management module socket 325 that is partof SIP management module 330. This structure facilitates the X-SIPclient module 310 being implemented in one programming language, such asC++, and the SIP management module 330 being implemented in a differentprogramming language, such as Java. It is particularly advantageous thatSIP management module 330 be implemented in a platform-independentenvironment such as Java, in order to facilitate offering services froma variety of platforms. However, as those of ordinary skill in the artwill appreciate, the choice of a platform independent language may varydepending upon system implementation and platform dependent languagesmay also be used without departing from the spirit and scope of theinvention.

[0044] In a preferred embodiment, the sockets 315, 325 and 335 arestandard TCP sockets and communication link 320 is a TCP communicationlink. Alternatively, the sockets 315, 325 and 335 may be UDP sockets, orthe like. Using standard TCP sockets for communications allows X-SIPclient module 310 and SIP management module 330 to run on independentcomputing systems that do not share processor, memory, clock, runtimesupport system, etc., common to a single computer platform. In otherwords, the client application 340, using a service from the SIP server104 via SIP management module 330; may be distributed with respect tothe SIP management module 330.

[0045]FIG. 4 is an exemplary block diagram illustrating the flexibilityand advantages of the SIP client manager 300 in accordance with apreferred embodiment of the invention. The system 400 includes a singleSIP management module 330 and three client applications 410, 420 and 430communicating with the same SIP server 104. In this exemplaryembodiment, system 400 contains a C++ application 410, an ADAapplication 420, and a C application 430, that may each initiatesessions with SIP server 104. The X-SIP client module 415, written inC++, communicates with SIP management module 330 via TCP sockets 417,419 and the TCP communication link 418. In a similar manner, X-SIPclient module 425, written in ADA, communicates with the SIP managementmodule 330 using TCP sockets 427, 429 and TCP communication link 428 andX-SIP client module 435, written in C, communicates with the SIPmanagement module 330 using TCP sockets 437, 439 and TCP communicationlink 438.

[0046] SIP client manager 300 allows client applications 410, 420 and430, written in a variety of programming languages, to share a singleSIP management module 330 using separate communication links. Theseclient applications 410, 420 and 430 may be, for example, resident onthree different machines with the SIP management module 330 on a fourthmachine. Alternatively, two or more of the client applications 410, 420and 430 may be resident on the same machine or may be resident on thesame machine as the SIP management module 330. Any manner of integratingand/or distributing the client applications 410, 420 and 430 and the SIPmanagement module 330 is intended to be within the spirit and scope ofthe present application.

[0047] Much of the detailed work of implementing a SIP client iscontained in the SIP management module 330 and need not be implementedin each of the X-SIP client modules 415, 425 and 435. Once an X-SIPclient module 415, for example, is written in one language, such as C++,it can interface with many applications, all written in C++. Therefore,as will be explained more fully below, the application programmerhandles callback functions appropriate for the client applicationwithout handling all of the details concerned with the state and contextof the session that must be supplied or returned in the outgoingmessages.

[0048] While the above description is directed to a client applicationcommunicating with a SIP server 104, the invention is not limited tosuch an embodiment. Rather, the client application may communicatedirectly with another client application using SIP so long as bothclient applications include a SIP client manager 300 for facilitatingconversion from client application messages to SIP messages and viceversa.

[0049]FIG. 5, shows an exemplary block diagram illustrating how a SIPclient manager 300 can be used with a TCP/IP network 520 in accordancewith a preferred embodiment of the invention. As shown in FIG. 5, theclient application 510 communicates with the TCP/IP network 520 throughSIP client manager 300. When communicating with Java application 550,SIP messages are routed through the SIP proxy server 530. The messagesare processed by SIP client manager 540 before transfer to the Javaapplication 550.

[0050] As mentioned above, it is also possible for two SIP clientmanagers to communicate directly. For example, SIP client manager 300may transmit messages directly to SIP client manager 560 and may receivemessages directly from SIP client manager 560. The messages areprocessed by SIP client manager 560 before transfer to C Application570.

[0051]FIG. 6 is an exemplary block diagram illustrating the major classgroups for the X-SIP Client Module in accordance with the preferredembodiment of the invention. In object technology, a class is auser-defined data type that defines a collection of objects that sharethe same characteristics. An object, or class member, is one instance ofthe class. Concrete classes are designed to be instantiated. Abstractclasses are designed to pass on characteristics through inheritance. Theclasses shown in FIG. 6 will be discussed in terms of C++ classes,however this X-SIP client module 300 could also be implemented in otherprogramming languages, such as ADA, C, and the like.

[0052] The X-SIP client module provides an interface to the clientapplication. In particular, the X-SIP client module provides calls to aSIP stack for various message types (invite, acknowledge, cancel, etc.)and calls back to the client application for the same types of messages.Handling of responses is through callback functions. The X-SIP clientmodule provides an abstract callback class 610 where the actualimplementation is in a CallbackImpl class defined for the particularapplication. This is appropriate since the action to be performed forvarious responses from the SIP server 104 is dependent on theapplication itself and is not part of SIP.

[0053] The X-SIP client module provides SIP API 620 primarily forcommunicating with MessageProcessorClasses 630 to send requests andreceive responses. The MessageProcessorClasses 630 rely onMessageDataClasses 650 and MessageHeaderClasses 640 to carry out thedetails of sending and receiving responses, as will be described in moredetail below. The SIP Connection 660 class actually performs the sendand receive operations though the TCP socket associated with the X-SIPclient module. FIG. 7 is an exemplary diagram illustrating a classhierarchy of the message processor classes in accordance with apreferred embodiment of the invention. The primary methods associatedwith each class are listed. In object technology, a method is theprocessing that an object performs. When a message is sent to an object,the method is implemented. Constructors, destructors, and utilitymethods are not included in these lists.

[0054] The SipMessageProcessor class 710 is an abstract class containingmethods to handle the seven message types: Ack, Bye, Cancel, Invite,Options, Register, and Response. Since all these methods are abstract,they must be defined completely in the appropriate implementationclasses.

[0055] The SipOutgoingMessageProcessor class 720 adds additionalabstract methods appropriate for sending messages. In particular, thereis a send method for each of the seven message types. TheSipOutgoingMessageProcessorImpl class 740 is a concrete class thatactually implements the fourteen abstract methods from the parentclasses.

[0056] The SipIncomingMessageProcessor class 730 adds a single abstractmethod appropriate for receiving messages, namely the method recv. TheSipIncoming MessageProcessorImpl class 750 is a concrete class thatactually implements the eight abstract methods from the parent classes.

[0057]FIG. 8 is an exemplary diagram illustrating a class hierarchydiagram for the message data classes in accordance with a preferredembodiment of the invention. As shown in FIG. 8, the SipMessageDataclass 810 contains a variety of methods to process the message headersand the message body of a SIP message. The names of the methods indicatetheir functionality and include several get methods.

[0058] The SipMessageDataHandler class 820 adds a single abstractmethod, processDataForSipMessage. Implementation of this method isdelayed until the appropriate subclass. The SipMessageDataHandler is theoverall container of the SIP message data. The processDataForSipMessagemethod decodes the SIP message based on an appropriate subclass.

[0059] The SipMessageDataHandler class 820 is divided into twosubclasses: SipRequestMessageData 830 for request messages andSipReponseMessageData 840 for responses. There are six request messagetypes with each of the six request message types having a subclass:SipOptionsData 850, SipAckData 870, SipCancelData 890, SipByeData 895,SipRegisterData 880, and SipInviteData 860. The parent class,SipRequestMessageData 830, contains methods getMethod, getURL, andsetURL that are available to the subclasses. Each subclass implementsthe abstract methods processDataForSipMessage and alloc. TheSipReponseMessageData class 840 implements the abstract methodsprocessDataForSipMessage, alloc, and get/set methods for StatusCode andReasonPhrase.

[0060] In object-oriented programming, it is fairly common to writefactory classes associated with other classes. This approach allowsdeferral of instance creation to the appropriate subclass.SipMessageDataFactory 805 is such a class. The getAllocateMethod returnsan alloc method appropriate for the subclass.

[0061]FIG. 9 is an exemplary class hierarchy diagram illustrating theheader classes in accordance with the preferred embodiment of theinvention. Header 910 is the parent class that contains a get method forthe header type. Subclass SipHeader 920 contains four abstract methods(parse, getType, toString, and validate) and two other methods (isparsedand toXmitString). There are eight types of headers processed:

[0062] SipXSipHeader 930, SipCseqTypeHeader 940, SipCallIDHeader 950,SipFromHeader 960, SipToHeader 970, SipContentLengthHeader 980,SipContent Type Header 990, and SipContact Header 995.

[0063] In addition to implementing the four abstract methods fromSipHeader 920, an alloc method is implemented, an output method, andget/set methods as appropriate for the header type. Finally,SipHeaderFactory 905 defers instance creation to the appropriatesubclass of header types.

[0064] An example event flow of the X-SIP client module 310 will now bedescribed with reference to FIGS. 10 and 11 and various classes fromFIGS. 6-9. While FIGS. 10 and 11 illustrate an invite message, othermessage types are processed in a similar manner. FIGS. 10 and 11 aresimplified diagrams in that all details are not shown, such as the useof the factory methods. However, FIGS. 10 and 11 provide an overview ofhow the classes described above work together to process requests to andfrom a SIP server 104.

[0065]FIG. 10 is an exemplary event flow diagram illustrating thegeneral processing of an outgoing message in accordance with a preferredembodiment of the invention. As shown in FIG. 10, in step 1010, theappropriate request message callback 610 (FIG. 6) is first invoked, theinvite request in the present example. In step 1015, the callback ispassed through the SIP API 620 (FIG. 6) to the SipOutgoingMessageProcessorImpl 740 (FIG. 7). In step 1020, the outgoing messageprocessor calls the SipMessageDataHandler 820 (FIG. 8) which in step1025, calls SipInviteData 860 (FIG. 8). SipInviteData 860 returns itsresult to SipOutgoing MessageProcessorImpl 740, in step 1030, which thenformulates the desired message based on interactions (steps 1035-1050)with SipHeader 920 and SipXSipHeader 930 (FIG. 9).

[0066] Once the appropriate message is formed, it is sent toSipConnection 660 (FIG. 6), in step 1055, for transmission through theTCP socket to the SIP management module 330, described in more detailfurther below. The SIP management module 330 then sends the SIP requestto the remote SIP Server 104.

[0067]FIG. 11 is an exemplary event flow diagram illustrating thegeneral processing of an incoming message in accordance with a preferredembodiment of the invention. As shown in FIG. 11, in step 1110, theincoming message is processed by the SIP management module 330 andpassed to SipConnection 660, which, in turn, passes the message on toSipIncomingMessageProcessorImpl 750 in step 1115. The incoming messageprocessor uses methods from SipXSipHeader 930 (steps 1120 and 1125),SipInviteData 860 (steps 1130 and 1135), and SipHeader 920 (steps 1140and 1145) to process the response. Then, in step 1150, SipDataHandler820 is called which, in step 1155, calls SipInviteData 860 to pass afinal response back to SipIncomingMsgProcessorImpl 750 (step 1160). Instep 1165, SipIncomingMsgProcessorImpl 750 calls the SIP API 620 whichthen, in step 1170, forwards the request to the client applicationthrough SipCallbackImpl 660.

[0068]FIG. 12 is an exemplary data flow diagram illustrating the majorprocessing components of the SIP client manager 300 in accordance with apreferred embodiment of the invention. The top part of the diagramillustrates a request being sent from a client application through theSIP client manager 300 to a SIP server 104 on an IP network 1210. Thebottom part of the diagram illustrates the processing of a response fromthe SIP server 104 on the IP network 1210 through the SIP client manager300 and back to the client application.

[0069] X-SIP client module 1215 contains an encoder for encoding theoutgoing request. The outgoing request is encoded so that it forms amessage with a start line, a sequence of header lines, a blank line toindicate the end of the headers, and an optional message body, asdescribed above. The SIP management module contains socket API 1220 forcommunication with X-SIP client module 1215. The socket API 1220includes a decoder to decompose the message into its constituent parts.

[0070] Two of the major components of the SIP management module arecontext manager 1230 and the state machine 1240. Context managementperformed by the context manager 1230 includes management of theessential components, e.g., CallerID, To, From, and other information,e.g., the Via Headers, in the SIP messages. The SIP standard provides anoutline of a state machine, however the invention goes beyond this basicfunctionality, particularly with regard to error handling. SIP socket1250 provides an interface for the SIP client manager 300 to SIP server104 via the IP Network 1210.

[0071] With the elements shown in FIG. 12, the X-SIP client module 1215encodes a message from the client application with essential informationsuch as the “To”, “From” and “CallerID” headers. The message is sent tothe context manager 1230 of the SIP management module via the socket API1220. The context manager 1230 stores, for example, the essentialinformation from the message and provides other non-essentialinformation, such as routing headers, to be encoded in the message. Thestate machine 1240 responds to events and determines the next action tobe taken. The message information is then forwarded to the SIP socket1250 which encodes the message, including the routing information, andtransmits the message to the SIP server 104 via the IP network 1210.

[0072] The process is reversed when a response message is sent from SIPServer 104 to SIP socket 1250 where the message is decoded. ContextManager 1230 maintains all the routing information and strips thisinformation from the message sent to the client application. Inparticular, the headers for Via, Route, and Record Route are removed andretained in SIP management module context manager 1230. SIP managementmodule state machine 1240 determines the appropriate action based on theevents that have occurred. The response is forwarded to API socket 1220for encoding and transfer using, for example TCP, to X-SIP client module1215. X-SIP client module 1215 decodes the message and passes it to theclient application for processing.

[0073] The advantages of separating the SIP client manager into an X-SIPclient module 1215 and a SIP management module 1230, 1240 thatcommunicate via, for example, a TCP link include an ability to beimplemented in different languages and possibly distributed on differentcomputer systems. Once processing has been distributed between machines,the system has the responsibility of insuring the components arecommunicating properly. This is handled in the SIP client manager byproviding heartbeat checks 1260. At predetermined time intervals, X-SIPclient module 1215 sends a heartbeat message to socket API 1220 in theSIP management module. This message is detected during the decodingprocess and a heartbeat response is sent back from the encoder of socket1220 to X-SIP client module 1215. When the X-SIP client module 1215decoder recognizes the heartbeat response, it knows that thecommunications channel is functional. If no response is received after areasonable delay time, dependent on the actual system environment,another heartbeat message is sent. If no response is received afterseveral heartbeat messages, the application program can be notified of acommunications exception and take appropriate action.

[0074] With reference now to FIG. 13, a structural diagram illustrates ahierarchical view of the major processing components of the SIP clientmanager in accordance with a preferred embodiment of the invention. FIG.13 can be contrasted with the data flow diagram in FIG. 12 which showssome of the same components, such as SIP socket 1250.

[0075] The input/output controller 1310 controls the informationtransfer between the SIP management module and the X-SIP client modulesocket. The context manager 1320 keeps track of the routing informationfor messages, either removing this information from the message beforesending the message to the application or adding this information when amessage is being sent to the IP network. The state machine 1330 respondsto events and determines the next action. This state machine 1330 may beextended beyond that specified by the SIP standard and, in particular,may be more robust in handling error conditions. The input/outputcontroller 1340 controls the transfer of information with the SIP serveron the IP network.

[0076] For example, the application may send a request to the SIPmanagement module via a TCP connection 1345. The input/output controller1310 decodes this request and sends information 1350 to context manager1320. The context manager 1320 uses the “To,” “From,” and “CallerID”headers to determine if a context already exists or if one has to becreated. Message 1355, with complete routing information is sent tostate machine 1330. The state machine 1330 determines the next action orif an error has occurred. Request 1360 is then forwarded to theinput/output controller 1340 for encoding. Encoded message 1365 is sentto the SIP server on the IP network.

[0077] The SIP server on the IP network may respond to the request withencoded message 1365 coming into the input/output controller 1340 fordecoding. Decoded message 1370 is sent to context manager 1320 forprocessing. Since this is an incoming message, the routing informationis removed and stored. If the state machine 1330 exists for thiscontext, then response 1355 is sent forward. If there is no statemachine yet for this context, then state machine 1330 is created andmessage 1355 is forwarded to it. The state machine 1330 determines thenext action or if an error has occurred. A response 1375 is thenforwarded to the input/output controller 1310 for encoding. The encodedmessage 1345 is sent to the client application via the TCP connection.

[0078]FIG. 14 is an exemplary block diagram for comparing the statusline for a normal SIP message 1410 and a X-SIP header 1420 used inaccordance with a preferred embodiment of the invention. The top part ofthe diagram shows a standard SIP status line 1410. The bottom part ofthe diagram shows an X-SIP header 1420 that is similar to the SIP statusline 1410 except that some information has been removed (e.g., theversion numbers 1413 and 1418) and additional information has been addedconcerning error tracking 1423, 1427 and 1428. The communicationsbetween the X-SIP client module socket and the SIP management module usethe X-SIP header 1420 format while communications between the SIPmanagement module and the SIP server on the IP network use the standardSIP status line 1410. The SIP management module provides the conversionbetween these formats.

[0079] According to the SIP standard, status line 1410 contains response1411, which, in turn, contains version number 1413, status code 1414,and reason phrase 1415. SIP status line 1410 contains request 1412,which, in turn, containing method 1416, Uniform Resource Identifier(URI) 1417 and version number 1418.

[0080] There are two primary differences between the SIP status line1410 and the X-SIP header 1420: the version number information 1413 and1418 is removed and new error information 1423, 1427 and 1428 is added.In particular, X-SIP header 1420 contains method 1421 which in turncontains response 1422, Uniform Resource Identifier (URI) 1426 and error1423. The response 1422 contains status code 1424 and reason phrase1425. The error 1423 contains error code 1427 and reason phrase 1428.

[0081] The significance of the difference between the SIP status line1410 and the X-SIP header 1420 is that the X-SIP header 1420 is able totransfer information that is not transferrable using the SIP header. Inother words, the SIP header cannot support the error header 1423.

[0082] For example, if a client application sends an improperlyformatted SIP message, an error will occur when the SIP message isparsed for the various header information. The identification of thiserror may be forwarded to the recipient client application using theerror header 1423. Thus, even though an error has occurred in thetransmission of a SIP message to the recipient client application, therecipient client application may be informed of the error and may beable to recover some of the SIP message information. In this way, theentire SIP message will not be lost due to an error in formatting andsome, if not all, of the SIP message may be recoverable.

[0083] Thus, with the present invention, client applications do not needto know the details of routing information for forwarding clientapplication messages to a server or other client application. The SIPclient manager applies SIP message routing information to outgoingmessages and strips off the routing information from received SIPmessages. Furthermore, with the present invention, a single SIP clientmanager may be used with a plurality of client applications runningunder different programming languages and different client applicationmessage formats.

[0084] It is important to note that while the present invention has beendescribed in the context of a fully functioning data processing system,those of ordinary skill in the art will appreciate that the processes ofthe present invention are capable of being distributed in the form of acomputer readable medium of instructions and a variety of forms and thatthe present invention applies equally regardless of the particular typeof signal bearing media actually used to carry out the distribution.Examples of computer readable media include recordable-type media such afloppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-typemedia such as digital and analog communications links.

[0085] The description of the present invention has been presented forpurposes of illustration and description, but is not intended to beexhaustive or limited to the invention in the form disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art. For example, the present invention is not limited to anetwork distributed system as all of the application and SIP clients maybe present within a single data processing system. The embodiment waschosen and described in order to best explain the principles of theinvention, the practical application, and to enable others of ordinaryskill in the art to understand the invention for various embodimentswith various modifications as are suited to the particular usecontemplated.

What is claimed is:
 1. A method in a communications system for processing a message in a text based communications protocol, the method comprising: receiving a first message from a source application, wherein the first message includes routing information for routing the first message between the source application and a target application, and information used by the target application; generating a second message from the first message, wherein the second message includes only the information used by the target application; storing the routing information, wherein the stored routing information is used when sending a response; and sending the second message to the target application.
 2. The method of claim 1, wherein the step of storing routing information forms stored routing information, the method further comprising: receiving a first response message from the target application; generating a second response message from the first response message and the stored routing information; and transmitting the second response message as the response to the source.
 3. The method of claim 1, wherein the receiving, generating, sending and storing steps are performed in a management module using the text based communication protocol.
 4. The method of claim 1, wherein the target application is a C++ application.
 5. The method of claim 1, wherein the source application is a Session Initiation Protocol (SIP) application.
 6. The method of claim 1, wherein the text based communication protocol is a Session Initiation Protocol (SIP).
 7. The method of claim 1, wherein storing the routing information forms stored routing information and wherein the stored routing information is used to route a response signal from the target application back to the source application.
 8. The method of claim 1, wherein the first message is a Session Initiation. Protocol (SIP) message and the source application is a SIP entity.
 9. The method of claim 1, wherein the second message is a simplified Session Initiation Protocol (SIP) message and the target application is an X-SIP client module.
 10. A method for communicating a message, comprising the steps of: receiving the message; determining session context information associated with the message, the session context information including message routing information; storing the message routing information, wherein the stored message routing information is used when sending a response signal; modifying the message based on the message routing information; and forwarding the modified message.
 11. The method of claim 10, wherein the message routing information includes at least one of a via header, a route header and a record route header.
 12. The method of claim 10, wherein modifying the message based on the message routing information includes removing the message routing information from the message.
 13. The method of claim 10, wherein modifying the message based on the message routing information includes adding the message routing information to the message.
 14. The method of claim 12, wherein the message is received from a server.
 15. The method of claim 13, wherein the message is received from a client application.
 16. The method of claim 10, further comprising: receiving a client application message from a client application; and converting the client application message into the message, wherein the message is a simplified Session Initiation Protocol (SIP) message.
 17. The method of claim 16, wherein the simplified SIP message does not include the message routing information.
 18. The method of claim 16, wherein modifying the message based on the message routing information includes adding at least one of a “Via” header, a “Route” header, and a “Record Route” header to the simplified SIP message.
 19. The method of claim 10, wherein the step of receiving the message further comprises: receiving the message at an input/output controller; decoding the message; and forwarding the decoded message to a context manager.
 20. The method of claim 10, further comprising: determining session state information associated with the message; determining a next session state based on the message and the associated session context information or the associated session state information; and forwarding the modified message to an input/output controller.
 21. The method of claim 10, wherein the step of forwarding the message further comprises: encoding the modified message at an input/output controller; and forwarding the modified message through a socket.
 22. The method of claim 10, wherein the modified message is an outgoing message to a Session Initiation Protocol (SIP) server, and wherein the modified message is forwarded using IP data packets.
 23. The method of claim 10, wherein the message is received from a Session Initiation Protocol (SIP) client module.
 24. The method of claim 23, wherein the SIP client module encodes the message.
 25. The method of claim 10, wherein the modified message is an incoming message, and wherein the modified message is forwarded using TCP packets.
 26. The method of claim 25, wherein the modified message is received by a Session Initiation Protocol (SIP) client module.
 27. The method of claim 26, wherein the SIP client module decodes the modified message.
 28. The method of claim 10, wherein the message is a Session Initiation Protocol (SIP) message received from a SIP entity.
 29. The method of claim 10, wherein the message is a simplified Session Initiation Protocol (SIP) message received from an X-SIP client module.
 30. A data processing system for communicating using a text based communication protocol, the data processing system comprising: first receiving means for receiving a message; session context information determination means for determining session context information associated with the message, the session context information including message routing information; first storing means for storing the message routing information; modification means for modifying the message based on the message routing information; and first forwarding means for forwarding the modified message.
 31. The data processing system of claim 30, wherein the message routing information includes at least one of a via header, a route header and a record route header.
 32. The data processing system of claim 30, wherein the modification means modifies the message by removing the message routing information from the SIP message.
 33. The data processing system of claim 30, wherein the modification means modifies by adding the message routing information to the message.
 34. The data processing system of claim 32, wherein the message is received from a server.
 35. The data processing system of claim 33, wherein the message is received from a client application.
 36. The data processing system of claim 30, further comprising: second receiving means for receiving a client application message from a client application; and conversion means for converting the client application message into the message, wherein the message is a simplified Session Initiation Protocol (SIP) message.
 37. The data processing system of claim 36, wherein the simplified message does not include the message routing information.
 38. The data processing system of claim 36, wherein the modification means modifies the message by adding at least one of a “Via” header, a “Route” header, and a “Record Route” header to the simplified SIP message.
 39. The data processing system of claim 30, wherein the first receiving means includes an input/output controller for receiving the message, a decoder for decoding the message, and a second forwarding means for forwarding the decoded message to a context manager.
 40. The data processing system of claim 30, further comprising: session state information determination means for determining session state information associated with the message; next session state determination means for determining a next session state based on the message and the associated session context information or the associated session state information; and second forwarding means for forwarding the modified message to an input/output controller.
 41. The data processing system of claim 30, wherein the first forwarding means includes: an encoder for encoding the modified message at an input/output controller; and a second forwarding means for forwarding the modified message through a socket.
 42. The data processing system of claim 30, wherein the modified message is an outgoing message to a Session Initiation Protocol (SIP) server, and wherein the modified message is forwarded using IP data packets.
 43. The data processing system of claim 30, wherein the message is received from a Session Initiation Protocol (SIP) client module.
 44. The data processing system of claim 43, wherein the SIP client module encodes the message.
 45. The data processing system of claim 30, wherein the modified message is an incoming message, and wherein the modified message is forwarded using TCP packets.
 46. The data processing system of claim 45, wherein the modified message is received by a Session Initiation Protocol (SIP) client module.
 47. The data processing system of claim 46, wherein the SIP client module decodes the modified message.
 48. The data processing system of claim 30, wherein the message is a Session Initiation Protocol (SIP) message received from a SIP entity.
 49. The data processing system of claim 30, wherein the message is a simplified Session Initiation Protocol (SIP) message received from an X-SIP client module.
 50. A computer program product in a computer-readable medium for use in a data processing system for communicating a message, the computer program product comprising: first instructions for receiving the message; second instructions for determining session context information associated with the message, the session context information including message routing information; third instructions for storing the message routing information; fourth instructions for modifying the message based on the message routing information; and fifth instructions for forwarding the modified message.
 51. The computer program product of claim 50, wherein the message routing information includes at least one of a via header, a route header and a record route header.
 52. The computer program product of claim 50, wherein the fourth instructions include instructions for removing the message routing information from the message.
 53. The computer program product of claim 50, wherein the fourth instructions include instructions for adding the message routing information to the message.
 54. The computer program product of claim 50, further comprising: sixth instructions for receiving a client application message from a client application; and seventh instructions for converting the client application message into the message, wherein the message is a simplified Session Initiation Protocol (SIP) message.
 55. The computer program product of claim 54, wherein the simplified SIP message does not include the message routing information.
 56. The computer program product of claim 54, wherein the fourth instructions include instructions for adding at least one of a “Via” header, a “Route” header, and a “Record Route” header to the simplified SIP message.
 57. The computer program product of claim 50, wherein the first instructions include instructions for receiving the message at an input/output controller, instructions for decoding the message, and instructions for forwarding the decoded message to a context manager.
 58. The computer program product of claim 50, further comprising: sixth instructions for determining session state information associated with the message; seventh instructions for determining a next session state based on the message and the associated session context information or the associated session state information; and eighth instructions for forwarding the modified message to an input/output controller.
 59. The computer program product of claim 50, wherein the fifth instructions include: instructions for encoding the modified message at an input/output controller; and instructions for forwarding the modified message through a socket.
 60. The computer program product of claim 50, wherein the modified message is an outgoing message to a Session Initiation Protocol (SIP) server, and wherein the modified message is forwarded using IP data packets.
 61. A data processing system for communicating using a text based communication protocol, the data processing system comprising: a network interface; and a client manager, wherein the client manager receives messages through the network interface, and wherein the client manager comprises a message modifier for modifying incoming messages and outgoing messages in accordance with context information associated with a message, wherein the context information includes message routing information.
 62. The data processing system of claim 61, wherein the message routing information includes at least one of a via header, a route header and a record route header.
 63. The data processing system of claim 61, wherein the message modifier modifies the message by removing the message routing information from the message.
 64. The data processing system of claim 61, wherein the message modifier modifies the message by adding the message routing information to the message.
 65. The data processing system of claim 63, wherein the message is received from a server.
 66. The data processing system of claim 64, wherein the message is received from a client application.
 67. The data processing system of claim 61, wherein the client manager receives a client application message from a client application and converts the client application message into the message, wherein the message is a simplified SIP message.
 68. The data processing system of claim 67, wherein the simplified SIP message does not include the message routing information.
 69. The data processing system of claim 67, wherein the message modifier modifies the message by adding at least one of a “Via” header, a “Route” header, and a “Record Route” header to the simplified SIP message.
 70. The data processing system of claim 61, wherein the client manager includes an input/output controller for receiving the message and a decoder for decoding the message.
 71. The data processing system of claim 61, wherein the client manager determines session state information associated with the message and determines a next session state based on the message and the associated session context information or the associated session state information.
 72. The data processing system of claim 61, wherein the client manager includes: an encoder for encoding the modified message at an input/output controller; and a socket for forwarding the modified message.
 73. The data processing system of claim 61, wherein the modified message is an outgoing message to a Session Initiation Protocol (SIP) server, and wherein the modified message is forwarded using IP data packets.
 74. The data processing system of claim 61, wherein the message is a Session Initiation Protocol (SIP) message received from a SIP entity.
 75. The data processing system of claim 61, wherein the message is a simplified Session Initiation Protocol (SIP) message received from an X-SIP client module. 